Hi,

That should work (Except "true" isn't defined.  Use "TRUE" or 1) and be about as efficient as possible.

However User Programs only execute periodically in time slices and the SnapAmp IO only updates every Servo Sample (90us) so don't expect this to work for something that changes faster than every 180us or so.

There is no interrupt capability for IO

Regards

TK

 

I have a differential input (70) that I want to output as a GPIO (80) to feed to a device that doesn't understand differential.
The obvious way appears to be something like:

    int bit70;
    SetBitDirection(70, 0);
    SetBitDirection(80,1);
    while (true)
        {
            SetStateBit(80, ReadBit(70));
        }

Could make this a bit "fancier" by watching for  bit70 to change state and only calling SetBit or ClearBit when the state changes. However, that still requires reading bit 70 in the loop.


Is there a way to set an interrupt (or something like one) to look for a change to input 70 so we're not constantly reading the bit in the loop (not that it takes much time)?



           

--
“Facts do not cease to exist because they are ignored.”
― Aldous Huxley, Complete Essays 2, 1926-29

“The good thing about science is that it's true whether or not you believe in it.”
― Neil deGrasse Tyson

Hi,

That should work (Except "true" isn't defined.  Use "TRUE" or 1) and be about as efficient as possible.

However User Programs only execute periodically in time slices and the SnapAmp IO only updates every Servo Sample (90us) so don't expect this to work for something that changes faster than every 180us or so.

There is no interrupt capability for IO

Regards

TK

I'm expecting pulses at more like 1 pulse per second. What's more important to me is that the delay between the incoming pulse and the outgoing pulse have a narrow window. The delay itself isn't important, just the variance in the delay.

--
“Facts do not cease to exist because they are ignored.”
― Aldous Huxley, Complete Essays 2, 1926-29

“The good thing about science is that it's true whether or not you believe in it.”
― Neil deGrasse Tyson

 

On 2/14/2017 4:35 PM, Tom Kerekes tk@... [DynoMotion] wrote:

Hi,

That should work (Except "true" isn't defined.  Use "TRUE" or 1) and be about as efficient as possible.

However User Programs only execute periodically in time slices and the SnapAmp IO only updates every Servo Sample (90us) so don't expect this to work for something that changes faster than every 180us or so.

There is no interrupt capability for IO

Regards

TK

I'm expecting pulses at more like 1 pulse per second. What's more important to me is that the delay between the incoming pulse and the outgoing pulse have a narrow window. The delay itself isn't important, just the variance in the delay.

--
“Facts do not cease to exist because they are ignored.”
― Aldous Huxley, Complete Essays 2, 1926-29

“The good thing about science is that it's true whether or not you believe in it.”
― Neil deGrasse Tyson

Hi David,

I believe the delay should be between 90-270us for one user Thread running. If you use a User Sample Time Callback you should be able to tighten that up a bit and make it independent of the number of User Threads. 

The execution time of the code itself should be insignificant (maybe 1us). 

TK

I can't find anything on "User Sample Time Callback". Are you referring to the UserCallBack variable  defined in KMotionDef.h?
I've always been terrible at function ptr signatures. This is a function of no args that returns nothing, right?

If I'm understanding this right, the callback function will be called after every servo sample, which aligns with your comment that the timing is independent of number of threads

--
“Facts do not cease to exist because they are ignored.”
― Aldous Huxley, Complete Essays 2, 1926-29

“The good thing about science is that it's true whether or not you believe in it.”
― Neil deGrasse Tyson

Hi David,

See the examples UserCallBack.c and StopCallBack.c

 

On 2/14/2017 8:35 PM, Tom Kerekes tk@... [DynoMotion] wrote:

Hi David,

I believe the delay should be between 90-270us for one user Thread running. If you use a User Sample Time Callback you should be able to tighten that up a bit and make it independent of the number of User Threads. 

The execution time of the code itself should be insignificant (maybe 1us). 

TK

I can't find anything on "User Sample Time Callback". Are you referring to the UserCallBack variable  defined in KMotionDef.h?
I've always been terrible at function ptr signatures. This is a function of no args that returns nothing, right?

If I'm understanding this right, the callback function will be called after every servo sample, which aligns with your comment that the timing is independent of number of threads

--
“Facts do not cease to exist because they are ignored.”
― Aldous Huxley, Complete Essays 2, 1926-29

“The good thing about science is that it's true whether or not you believe in it.”
― Neil deGrasse Tyson